在開始動手前,我們再來解釋其他名詞 — GitHub Actions。
上網找的介紹:GitHub Actions 是 GitHub 提供的一個自動化平台,這個平台讓開發者能夠自定義一系列的工作流程,這些工作流程可以包括編碼樣式檢查、單元測試、整合測試、部署和更多。這些任務被封裝在一個 YAML 配置文件中,並可以由多種事件觸發,如推送(push)到分支、發出 Pull Request、手動觸發等。
簡單來說 GitHub Actions 就是 GitHub 自家開發的 CI/CD 工具,其他類似的工具有 TeamCity、Circle CI,當然還有面試的時候很常被問到、大名鼎鼎的 Jenkins。
GitLab 也有推出自己的 CI/CD 功能,就叫做 CI/CD Pipelines,Azure DevOps 也有 CI/CD 功能,而且 GitHub Actions Runner 其實就是從 Azure Pipelines Agent fork 出來的。
用 GitHub Actions 的好處就是界面全部整合在 GitHub,不用再去另外的網站設定,而且 GitHub Actions 也有很多現成的 Action 可以使用,不用自己寫。
Workflows: 這是一系列自動化指令的集合,定義在 .github/workflows
資料夾的多個 YAML 文件內。
Jobs: Workflows 由一個或多個 Jobs 組成。Jobs 是實際要執行的單個任務,比如建構、測試或部署。Jobs 可以同時執行,或依賴於其他 Jobs。
Steps: Jobs 包括多個 Steps,這些是在 Job 中執行的個別任務。每一個 Step 可以執行命令或使用預定義的 Action。
Actions: 由 GitHub 或社群提供的可重用元件,可用於執行常見任務,如 checkout code、安裝依賴或部署到某個平台。
Runners: 執行 Jobs 的實體或虛擬機器。GitHub 有提供一些免費的 runners,當然你也可以自家的環境設定你專屬的 runners。
Environment Variables: 在 workflow 中,你可以定義環境變數來存儲和管理敏感資訊,如密鑰。
Matrix Builds: 允許你在多個版本和配置下同時執行 Jobs,比如說同時 build Mac、Linux、Windows 的 binary,並同時執行測試或打包。
.github/workflows
的資料夾。main.yml
)。name: CI
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
對於我們的 RSS 閱讀器專案,我們可以設置一個基本的 CI 流程,這將在每次提交或發出 Pull Request 時自動執行。這樣,不僅可以確保代碼的品質和可靠性,還可以節省人工測試的時間。
我們也可以加上一些更進階的功能,如自動部署到測試服務器,或者在成功執行所有測試後自動生成和發佈新版本。
GitHub Actions 是一個強大和靈活的工具,對於希望自動化他們的開發流程的開發者來說,這是一個不可或缺的資源。它的高度可定制性和強大的社群支持使其成為現代 CI/CD 工具的理想選擇。